home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / pc / FAQSYS18.ZIP / FAQS.DAT / VOXEL.TXT / text0000.txt < prev    next >
Encoding:
Text File  |  1994-08-09  |  3.3 KB  |  67 lines
  1. Whew!  After downloading and running MARS.EXE, I find myself stunned by how
  2. fast it worked and how realistic it looked....
  3.  
  4. I'm into programming my own demo now with a couple of friends.  Our new group
  5. is called Mindware, and our demo should be finished within the next month or
  6. so.  (No name yet)  I'm now fairly experienced with graphics manipulation (3d,
  7. X-mode, VGA registers, etc.), but I still am amazed how smooth MARS is.
  8.  
  9. Now I've pondered quite a bit how it's done.  My first impression would be a
  10. ray-tracing like algorithm, where a ray is traced (quickly, of course) from the
  11. viewpoint, through the screen, and over the heightfield, testing for
  12. intersections along the way.  But this seems like it would be far too slow for
  13. practical use (but it would certainly deal with the smoothness of the landscape
  14. and the order of mountains).
  15.  
  16. My next impression was a polygon subdivision algorithm.  Take four points from
  17. the heightfield that form a square, and draw that polygon.  Go from front to
  18. back on the heightfield, drawing only if that area hasn't been drawn on before.
  19. But this seems like too much time would be spent on calculating the edges of
  20. the polygon and filling it.
  21.  
  22. My final idea again involves going from front to back on the heightfield, but
  23. instead of drawing accurate polygons, just draw a rectangular region from the
  24. current point to the next point, with a flat top, descending down until the
  25. non-filled area ends.  (This is probably not a very good explanation. :)
  26.  
  27. So... any ideas anyone?  Tell me if my ideas are really naive :)  I might try
  28. coding some of these things to see if they work.
  29.  
  30. Thanks in advance, and watch for our forthcoming demo!
  31. -- 
  32. Kevin McCormick                           | "The more we try to control, the
  33. kmccorm@access.digex.net                  |  less we are really in control."
  34. IRC: Xenophon                             |        - Robert J. Oppenheimer
  35. This message is costing the net hundreds if not thousands of dollars to send.
  36.  
  37. From rc1.vub.ac.be!ub4b!EU.net!sun4nl!wtrlnd!tess!postmaster Tue Mar 15 11:23:54 1994
  38. Path: rc1.vub.ac.be!ub4b!EU.net!sun4nl!wtrlnd!tess!postmaster
  39. From: michiel@tess.wlink.nl (Michiel Ouwehand)
  40. Newsgroups: comp.sys.ibm.pc.demos
  41. Subject: Mars.uue (1/1)
  42. Message-ID: <762760829.AA03471@tess.wlink.nl>
  43. Date: Wed, 02 Mar 1994 09:12:01
  44. Sender: postmaster@tess.wlink.nl
  45. Lines: 19
  46.  
  47. Hello M.D.Griffiths!
  48.  
  49. [─∙· 28 Feb 94, M.D.Griffiths wrote to All: ·∙─]
  50.  
  51.  MDG> Yes it is a much more difficult proposition, since as it stands,
  52.  MDG> no rotation is done, you simply move left or right. I would
  53.  MDG> imagine that rotation would complicate things somewhat, perhaps
  54.  MDG> the original algorithm might not be applicable? It makes a nice
  55.  MDG> demo though :-). Would the author like to comment?
  56.  
  57. I am not hte author, but I would like to comment. What the author is doing (as I
  58. see it) is calculate a fractal (this will be the height map) and calculate
  59. light-rays over it (this will be the colour map). Then, when drawing, each point
  60. on the screen is an interpollated version ofmore of the heights and colours in
  61. the map. Rotating will take some time, but isn't impossible as I see it.
  62.  
  63. Groetjes,   _    (Icarus / T∙R∙I∙A∙L)   InterNet: michiel@tess.wlink.nl
  64. )\/(ichiel (_)uwehand                    FreeNet: 2:2802/108.11
  65.  
  66.  
  67.